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Een BIT toets beoogt in essentie antwoord te geven op twee vragen: streeft het project een helder doel 
na, c.q., lost het een probleem op ("business case") en is het project zo ingericht dat er vertrouwen kan 
zijn dat dat doel ook gehaald wordt ("slaagkans"). Het toetsteam gebruikt dit toetskader om zich snel 
een beeld te vormen van alle aspecten van een project en de daarmee samenhangende risico's. Het 
toetsteam selecteert daaruit de risico's die een grote invloed op de slaagkans hebben en stelt 
maatregelen voor om de slaagkans te vergroten. 

1. Business case en financiering 

Er is een duidelijke doelstelling en een business case die deze onderbouwt. In de businesscase zijn 
kosten en baten van het project tegen elkaar afgewogen. De meerwaarde van het project voor de 
organisatie, de eindgebruiker en/of de samenleving wordt door de business case aangetoond. De baten 
zijn waar mogelijk vertaald in financiële termen; als dat niet kan zijn de kwalitatieve baten concreet 
gespecificeerd op een wijze die achteraf geverifieerd kan worden. Er is (meerjarige) financiële dekking 
voor het project én voor de beheerfase. Het project past binnen de afgesproken kaders (geld, mensen, 
middelen). De opdrachtgever voor het project is ook verantwoordelijk voor het budget. 

2. Opdrachtgever en projectorganisatie 

De rollen, taken, verantwoordelijkheden en bevoegdheden in de projectorganisatie (opdrachtgever, 
projectmanager, projectteam, stuurgroep, projectsupport) zijn helder vastgelegd en worden ingevuld 
door mensen met voldoende kennis en ervaring. In en rond de projectorganisatie is aantoonbaar en 
structureel ruimte voor tegendenken en een kritische blik. In het projectplan is de kwaliteitsborging 
beschreven op basis waarvan de interne en externe toetsmomenten op de relevante projectmijlpalen/ 
producten zijn beschreven. 

3. Projectafhankelijkheden en risico's 

Voor de start van de uitvoering is goed zicht op de afhankelijkheid van andere projecten en releases van 
bestaande applicaties (inhoud en planning). Het is duidelijk hoe hierover afspraken zijn/worden gemaakt. 
De belangrijkste risico's van het project zijn in kaart gebracht en het risicomanagement is geborgd in de 
projectbeheersing. 

4. Samenhang werkprocessen en automatisering 

In de aanpak is expliciet gedefinieerd hoe de werkprocessen en automatisering in samenhang tot stand 
komen. Werkprocessen zijn een integraal onderdeel van de oplossing en zijn idealiter gedefinieerd en 
gestandaardiseerd voordat begonnen wordt met de realisatie van het systeem. Indien de daadwerkelijke 
invoering van de processen pas mogelijk is met het nieuwe systeem, dan zijn de nieuwe werkprocessen 
afdoende getoetst voordat begonnen wordt met selectie of bouw van het nieuwe systeem. Indien wordt 
gekozen voor een standaard pakketoplossing dan worden de werkprocessen in principe aangepast aan 
het pakket. 

5. Minimale omvang bij de start 

De omvang (scope) van het project is beschreven als op te leveren producten. Deze scope is aantoon¬ 
baar zo klein mogelijk gehouden, gegeven de gestelde doelen. Als de complexiteit te groot wordt en/of 
de doorlooptijd te lang, wordt gekozen voor een projectfase ring waarbij de doelen aantoonbaar in 
stappen worden bereikt. 

6. Beheersing van de omvang tijdens de looptijd 

Alleen de opdrachtgever kan na de start van het project nog aanvullende eisen stellen aan het eind¬ 
resultaat. Aanvullende eisen worden goedgekeurd op basis van een wijzigingsvoorstel waarin de impact 
is beschreven op tijd, kosten, kwaliteit, scope, risico's en baten. De opdrachtgever is verantwoordelijk 
voor alle consequenties van goedgekeurde wijzigingen en heeft hiervoor voldoende financiële ruimte. 

7. Realisatie van de baten 

Het is duidelijk wie verantwoordelijk is om de baten van het project te realiseren. De verantwoorde¬ 
lijken) heeft/hebben een duidelijk (intern of extern) belang om de baten te realiseren en de autoriteit 
en sturingsmogelijkheden om dit voor elkaar te krijgen. Indien voor de realisatie medewerking van 
andere partijen nodig is dan is medewerking van deze partijen verzekerd of minstens draagvlak bij deze 
partijen aangetoond. 
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8. Architectuur, functionele haalbaarheid en technische maakbaarheid 

De gekozen architectuur verdeelt het nieuwe systeem optimaal in componenten die apart opgeleverd en 
getest kunnen worden. Indien componenten door verschillende partijen worden gerealiseerd dan zijn de 
benodigde koppelvlakken (interfaces) vooraf gedefinieerd (technisch en semantisch), of is één partij 
geautoriseerd om deze voor de benodigde koppelvlakken te definiëren. De benodigde inspanning voor de 
realisatie van elk koppelvlak is in kaart gebracht. Voor zover van toepassing wordt gebruik gemaakt van 
de voor de overheid vastgelegde standaarden. Het project geeft invulling aan het principe: hergebruik 
vóór koop vóór bouw. Er wordt gebruik gemaakt van gangbare en volwassen technologie en zowel de 
organisatie als de geselecteerde marktpartijen hebben ervaring met de gekozen technische oplossingen. 
De haalbaarheid van het totaal aan functionele wensen is getoetst. Voor zover in het kader van het 
project nieuwe applicaties moeten worden ontwikkeld is de omvang hiervan bij benadering bekend, 
bijvoorbeeld door een functiepuntenanalyse. 

9. Belang van betrokken partijen 

Alle stakeholders bij het project zijn helder in kaart gebracht (inclusief de eventuele maatschappelijke 
groeperingen). Eventuele organisatorische en bestuurlijke risico's worden voortdurend helder in beeld 
gebracht en vertaald in maatregelen. Partijen die belang hebben bij het mislukken van het project, als ze 
er zijn, hebben geen invloed op het welslagen van het project. Als dit wel het geval is, dan is dit expliciet 
benoemd in de risico analyse en zijn adequate maatregelen getroffen. 

10. Bouw, fasering en opbrengst 

De ontwerp- bouw- en testfase van het project is zo kort mogelijk gehouden of is geïntegreerd in een 
Agile/Scrum aanpak. Na uiterlijk 2 jaar is de implementatie bij eindgebruikers begonnen. De 
implementatie wordt binnen 1 jaar afgerond. De eerste baten van het project zijn dan tevens 
gerealiseerd. 

Grotere, langer durende projecten zijn verdeeld in helder afgebakende fasen die aan bovenstaande 
doorlooptijden voldoen en die elk een positieve business case hebben, of minimaal leiden tot concreet 
bruikbare producten voor eindgebruikers. 

11. Aanbesteding 

De gekozen aanbestedingsstrategie balanceert de risico's tussen opdrachtgever en marktpartij(en) en 
koppelt betaling aan de behaalde en door de opdrachtgever geaccepteerde resultaten. De eenduidigheid 
en volledigheid van de (functionele) eisen is vóór de definitieve gunning aantoonbaar grondig getoetst, 
waarbij optimaal gebruik gemaakt is van pilots en/of prototypes om bruikbaarheid en acceptatie van het 
systeem te waarborgen. De voorgenomen aanbesteding, inclusief de belangrijkste 

aanbestedingsdocumenten, zijn vooraf in de markt getoetst en de resultaten van deze toetsing zijn in de 
aanbesteding verwerkt. Voor zover is afgeweken van de uitkomsten van deze toetsing is de motivatie 
hiervoor vastgelegd. De contractering is zodanig dat de bij de uitvoering betrokken marktpartijen er 
belang bij hebben dat het project tijdig en conform de initiële afspraken wordt opgeleverd. Er zijn 
reguliere overlegmomenten gepland waarin betrokken partijen in een zakelijke en coöperatieve sfeer de 
gemaakte afspraken evalueren. 

12. Implementatie en overdracht naar de lijn 

In het projectplan is voldoende tijd en geld gereserveerd voor documentatie, training (incl. ontwikkeling 
van trainingen, train de trainers), en overdracht aan en ingebruikname door de lijnorganisatie. Dat geldt 
ook voor de transitie naar de fase van beheer en onderhoud (incl. afspraken met eventuele externe 
leverancier). De lijnorganisatie inclusief de beheer- en onderhoudsorganisatie zijn aantoonbaar betrokken 
geweest bij het opstellen van deze plannen en hebben deze geaccepteerd. Er is duidelijk gedefinieerd en 
afgesproken wie de ICT-producten in beheer neemt en of hiervoor de benodigde resources beschikbaar 
zijn gesteld. Er is rekening gehouden met een nazorgfase. 

13. Acceptatie en decharge 

In het projectplan is duidelijk beschreven hoe de op te leveren producten worden getoetst en 
geaccepteerd en wat de acceptatiecriteria zijn. Tevens is aangegeven onder welke voorwaarden aan het 
project decharge wordt verleend door de opdrachtgever. 
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